docs(dev-docs): Add metrics telemetry specs #15178
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
chargome
changed the title
Co-authored-by: David Herberth <[email protected]>
|
|
||
| At minimum the SDK needs to implement the following methods for each metric type: | ||
|
|
||
| - `Sentry.metrics.increment(name, value, options)` - Increment a counter |
There was a problem hiding this comment.
| - `Sentry.metrics.increment(name, value, options)` - Increment a counter | |
| - `Sentry.metrics.count(name, value, options)` - Increment a counter |
There was a problem hiding this comment.
Can count take a negative integer/float?
There was a problem hiding this comment.
I think counters in metrics should be always increasing – but there is e.g. a separate up/down-counter in otel. We don't prevent passing negative integers from the SDK though
|
|
||
| `name` | ||
|
|
||
| : **String, required**. The name of the metric. This should follow a hierarchical naming convention using dots as separators (e.g., `api.response_time`, `db.query.duration`). |
There was a problem hiding this comment.
This should follow a hierarchical naming convention using dots as separators
Will this be enforced by the backend? Or just recommended to users? Are spaces in the name valid?
There was a problem hiding this comment.
I don't think we need to enforce this pattern, rather recommend it. I'd restrict whitespaces both in the SDK (trim) and the backend.
|
|
||
| `span_id` | ||
|
|
||
| : **String, optional**. The span id for the metric. |
There was a problem hiding this comment.
Is this is the span id of the parent span? Or does this represent the metric item itself? If it does, we can probably remove this from the client protocol.
There was a problem hiding this comment.
That would the be the current span atm
| : **Number, required**. The numeric value of the metric. The interpretation depends on the metric `type`: | ||
|
|
||
| - For `counter` metrics: the count to increment by (should default to 1) | ||
| - For `gauge` metrics: the current value | ||
| - For `distribution` metrics: a single measured value | ||
|
|
||
| Integers should be a 64-bit signed integer, while doubles should be a 64-bit floating point number. |
There was a problem hiding this comment.
Can you supply both an integer and a float to a metric? So call increment(3) and then increment(4.5)?
There was a problem hiding this comment.
I suggest we stick to integers for counters. @k-fish I assume the value eventually ends up in an EAP attribute where integers and floats go into separate columns. Mixing both types might then make queries tricky, plus you'd have to deal with precision loss for very large numbers.
There was a problem hiding this comment.
Tagging on to the discussion, is the SDK expected to truncate large integers? If so, how do we truncate, or do we just reject integers that are beyond 64 bits.
In particular, 64-bit floats are natural in Python, but integers are arbitrary precision (under the hood more memory is allocated if the user provides a large integer).
|
|
||
| At minimum the SDK needs to implement the following methods for each metric type: | ||
|
|
||
| - `Sentry.metrics.increment(name, value, options)` - Increment a counter |
There was a problem hiding this comment.
Can count take a negative integer/float?
| - `name` **String, required**: The name of the metric | ||
| - `value` **Number, required**: The value of the metric | ||
| - `options` **Object, optional**: An object containing the following properties: | ||
| - `unit` **String, optional**: The unit of measurement (distribution and gauge only) |
There was a problem hiding this comment.
Why can't we put units on counts?
There was a problem hiding this comment.
Isn't count the unit itself?
There was a problem hiding this comment.
Thanks for this @chargome 👍
A couple notes:
- This api might change before a beta takes place, so we may want to leave it up in PR for a while
- Metrics may have different limits than logs (eg. metric size limit is 2kib currently, might lower it) so may want to make note of that when it comes to adding attributes. We also probably need indicate what the failure mode should be if you have too much attribute data on the scope that you're trying to add to each metric
| : **Number, required**. The numeric value of the metric. The interpretation depends on the metric `type`: | ||
|
|
||
| - For `counter` metrics: the count to increment by (should default to 1) | ||
| - For `gauge` metrics: the current value | ||
| - For `distribution` metrics: a single measured value | ||
|
|
||
| Integers should be a 64-bit signed integer, while doubles should be a 64-bit floating point number. |
There was a problem hiding this comment.
Tagging on to the discussion, is the SDK expected to truncate large integers? If so, how do we truncate, or do we just reject integers that are beyond 64 bits.
In particular, 64-bit floats are natural in Python, but integers are arbitrary precision (under the hood more memory is allocated if the user provides a large integer).
Co-authored-by: Alex Krawiec <[email protected]>
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
Co-authored-by: Alex Alderman Webb <[email protected]>
Co-authored-by: Alex Alderman Webb <[email protected]>
sdk/telemetryformetrics./sdk/data-model/envelope-items/for the trace metric itemTook the logs specs as a template.
ref getsentry/sentry-javascript#17883